JPERF-273 AWS DC with hooks #117
Conversation
…8c91ecdedc494b3fc0c0eaf3
Add builder API to customize a `JiraNodeFlow` rather than replacing it. The alternative is to only keep the replacement API, but we need a compact way to get the default as a caller.
They can hook per instance rather than per node. There are two timings now: "pre-provision" and "instance URI available". They also have access to node hooks.
Bump infra to 99198b597776318aadc02b19b3123d8b03415dee
Bump infra to be7978ed60b8bf903483d33e82562a3444e08ff8
Start working on `Infrastructure` based on `Future<ProvisionedStack>`. It should be able to split into dedicated sub-infras for DC nodes, mysql, LB. Use `NfsSharedHome` from infra. Open question: who should decide which ports should be open: * `Infrastructure` impl because the network setup already exists for BTF or shared CloudFormation stack? * consumers of `Infrastructure`, because MySQL knows it works on 3306 and Samba knows it works on TCP 139, 445 and UDP 137, 138 * both, where consumers give hints, but infra has the last word?
infrastructure snapshot from 290dd1bfea2291cbf05e88f47610c15ba4528c72
Bump infra to 79b89cfb841dec34ce66e31b03ba6dbd477d2084
Open problems:
* plans shouldn't use resources, but some sub-plans require resources,
* e.g. `Ec2ServerRoom` (and others) require `SshKey` and `Vpc`
* make a "common resources" container and pass it via methods?
* OR figure out resource passing via constructors (like `Future<SshKey>`?)
* HTTP -> TCP -> SSH dependency chain doesn't match the real layers
* in reality SSH depends on TCP 22, not the other way around
* the problem is seen between `Ec2ServerRoom` and `AwaitingEc2`
* maybe we need to model multi-ports in TCP? but how to distinguish
HTTP 80 port from SSH 22 port or 3306 MySQL port? Samba needs many
* `AutoCloseable` vs `Resource` for deprovisioning
make it work, then refactor * maybe extract SSH/nonce/workspace/investment/network as a common resource and reuse across *separate* Jira/LB/VU
Build a bridge between LB formula (AWS) and LB plan (SSH). Copy `TokenScrollingEc2` from `aws-resources`. Bump infra to b6a4576d5059c323ad71ba55f9cb5a6151e097e3 to call preinstance hooks in parallel. Reuse `StackJiraNodes` instance, because it's stateful right now. Make `LegacyAwsInfrastructure` cheap to construct by deferring networking.
Consume infra ce8c26cd471ffe981bfb791be7fc218acf948e51 Next steps: * pristine Jira DC Plan unencumbered by `LegacyAwsInfrastructure` or CFN * bridge from `JiraInstancePlan` to `JiraFormula` if possible * bridge the other way around if possible * can `SambaSharedHome` really work with just `TcpNode`? * do we actually need `Reports` transport via S3? * do we need bulk/directory transport for `Reports`? * add jpt-workspace as CI artifact * make hook collections append-only (`PreInstanceHooks` already are)
|
@dagguh are you still planning to work on this or would you like to hand it over? |
|
I wanted to finish it, but when I heard rumors about outsourcing JPT, I got demotivated. |
|
In Jira DC we won't stop using JPT unless there will be a tool with similar functional and non-functional requirements (or I'm out and someone else responsible for our performance testing would accept lack of some non-functional requirements and make our tests to be replaced by a solution with less maintainability/extendability). I personally think the improvement in infrastructure setup flexibility is needed if we want to invest into our tests and it seems this is one of the priorities of the team. I thought this PR could be looked at again, though I'm not commiting that I will be able to help in any way around it yet. I will be honest that the way I'm used to modeling the systems is a bit in contrast to how those changes are made and actually how a lot of JPT is already written. I thought that I can use this opportunity to learn or possibly fix the implementation model. |
I see. I'll resurrect this. Note that I can only spend 20% of time, so if we need to speed up, we can pair up for partial handover. |
|
PS. This is widening the range of hypotheses that JPT can test. |
|
True, we also have experience with this kind of problems recently. We often are unable to tell what exactly caused the regression and with our policy of not introducing any regressions we end up being forced to look for improvements around an action instead of fixing the cause of it's regression. |
|
However I've got impression that right now our tests are not really representing scenarios close enough to real product usage. TBH I'm not even sure if it's practically possible to create a regression detection pipeline that will cover most of the cases that our users rely on. Cloud is better here. The other capability that JPT grants is an environment where devs can experiment. Team expects us to provide them the tooling for proving or disproving theories that they are creating based on their understanding of the product code. I feel like I fail miserably when they ask me how to test something and I need to tell them that we don't have an functionality out of the box. Test customisation in JPT is currently not easy enough. |
No description provided.